COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	mad[e86,jmc]	Memo to Nafeh
C00007 00003	Dear John:
C00010 ENDMK
C⊗;
mad[e86,jmc]	Memo to Nafeh

Dear John:

	It seems worthwhile to put on paper some of the conclusions
of our September 3 discussion, especially in view of the forthcoming
discussion with Rudy Baier.

1. The key question concerning MAD's relation with Baier and his group is
how to formulate a relation that will lead to a MAD product.
A plan that is appropriate for a university research group is unlikely
to be adequate for a company that needs products to survive.

2. Baier's general idea to combine AI with databases is a good one,
but the proposed MADLOG is not.  It would be a modest version of
Prolog suitable for experimentation within the Baier group, but
if it were to be used as a MAD product, it would have to be developed
as a competitor to AI shells like ART and KEE as well as to the
commercial versions of Prolog and Lisp.  This is impractical.

3. Therefore, it was proposed that Baier's group in collaboration
with MAD develop a general-purpose database interface that could
be used in connection with a variety of expert system shells.
Specifically, the group would prepare variants suitable for Common
Lisp, for Prolog, for ART and KEE.  At the other end, it would
work with whichever of SQL, Database3, etc. the customer wanted.
In particular, the client could work with several of these
systems in a single expert systems, because the expert system
might have to work with a variety of existing databases that
it couldn't demand to be put into a single format.

4. The companies that produce expert system shells all acknowledge
that access to databases is important to them.  However, so far
as I know, none of them has plunged into learning about the
different important existing database systems and languages in
order to interface to them.  Therefore, there is a niche for
MAD and its collaboration with the Baier group.

5. It will be necessary to be flexible about hardware in carrying
out this project.  For some purposes it will be necessary to make
the program work on other people's hardware.  KCL written in C
may be a suitable vehicle.  For still other purposes dedicated
hardware such as MAD's own machine will be essential.  The latter
will be true when the machine with the database is fully configured
for its existing systems, so that the expert system would have
to interact with the computer as a user.

6. My opinion is that variants of such a system might sell for
between $25K and $100K depending on the extent to which of the
expert system and the database interface was the dog and which
was the tail.

		Sincerely,
		
Dear John:

	This is the clarification you requested of the fifth point of my
previous memo.

	In many cases the interfaces between database systems and
expert system shells will have to inhabit either the computer
environment of the database or that of the shell (if they're
different).  In other cases, it may be necessary to use
separate computer equipment, and in this case there is an
opportunity to use the MAD 3 computer.

	The reason why separate equipment may be required is that
some computer systems are entirely dedicated to particular software.
Modifying this software may be infeasible either because the
users may not know how to do it or (more often) because they
need to maintain compatibility with expected future versions
of the same software to be obtained from somewhere else.
When such software contains the database system, the best solution
to interacting it may be to put the interface software in a
separate computer that interacts with the database computer
as though it were a user.

	I hope this clarifies the point I was making.  Let me
again emphasize that this is somewhat conjectural, and the actual
extent of the opportunity to use MAD hardware needs to be determined
by a market survey by someone familiar with the database systems
with which it may be necessary to interact.

Sincerely,